In file @apps/mobile/src/features/threads/ThreadRouteScreen.tsx around line 464:

`handleStopThread` checks `selectedThread.runtime` from the thread shell snapshot to decide whether to interrupt, but the busy/send state shown in the composer is derived from the projection in `useThreadComposerState()`. When the projection has an active run but the shell snapshot is stale, the composer shows the thread as busy while `handleStopThread` returns early without calling `threadEnvironment.interruptTurn`, making the Stop control a no-op for active runs. Consider basing the interrupt guard on the same projection-derived runtime state the composer uses.

Also found in 1 other location(s):
- apps/mobile/src/features/threads/ThreadComposer.tsx:316 -- `showStopAction` now follows `threadRuntimeIsActive(props.selectedThread.runtime)`, which treats `queued` as active. In a thread that only has server-queued runs, the collapsed composer switches its primary control from send/queue to the destructive stop pill, even though the expanded composer still labels the send action as `Queue`. This makes the collapsed composer show the wrong action and can cause users to cancel queued work instead of adding another queued message.

In file @apps/mobile/src/features/threads/ThreadDetailScreen.tsx around line 453:

When a thread has queued runs, the `ThreadQueueControl` panel rendered inside the floating overlay can overlap the `ThreadFeed` empty/unavailable placeholder, partially obscuring it. `estimatedOverlayHeight` only accounts for the composer chrome and `WorkingDurationPill`, but `ThreadQueueControl` also contributes to the overlay height. `ThreadFeed` receives that estimate as `contentBottomInset`, so it does not reserve enough space for the queue panel.

In file @apps/mobile/src/features/threads/ThreadDetailScreen.tsx around line 1:

The `ThreadRelationshipsBanner` passed as `topAccessory` is silently dropped whenever `contentPresentation.kind` is `"unavailable"` — `ThreadFeed` returns the placeholder early and never mounts the `ListHeaderComponent` that renders `topAccessory`, so the lineage banner and its detach/merge actions disappear when a thread is loading, disconnected, or unavailable. Consider rendering `topAccessory` in the placeholder path as well, or hoisting it above the early return in `ThreadFeed`.

In file @apps/server/scripts/record-cursor-agent-sdk-replay-fixture.ts around line 175:

`writeFixtureFiles` unconditionally overwrites `package.json` and `tsconfig.json` in the supplied `cwd`. When `T3_CURSOR_REPLAY_CWD` is set, `prepareWorkspace` returns that path with `remove: false`, so the script for `subagent`, `todo_list`, or `tool_call_read_only` overwrites the user's real project files and never cleans them up. Consider skipping `writeFixtureFiles` when `workspace.remove` is `false`, or writing fixture files into a subdirectory that is always cleaned up.

In file @apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts around line 418:

`loggedClaudeQueryOptions` copies `options.settings` verbatim into the native protocol log, so credentials passed via `launchArgs` (e.g. `--token=...`) are written to the provider event log in cleartext every time a Claude query is opened. `env`, `mcpServers`, and callbacks are already reduced to presence-only indicators (`hasEnvironment`, `hasMcpServers`, `hasCanUseTool`) to avoid leaking secrets, but `settings` — which contains the free-form `launchArgs` string — is logged in full. Consider applying the same redaction strategy to `settings` as is done for `env` and `mcpServers` (e.g. logging only `hasSettings: true`).

In file @apps/server/src/orchestration-v2/Adapters/AcpAdapterV2.ts around line 282:

`acpMcpServers` always emits `type: "http"` even for agents that advertise only `sse` MCP support, so SSE-only agents receive an incompatible server config and silently fail to connect to the MCP server — MCP tools stop working for that provider. The session's MCP endpoint transport should be derived from the agent's `mcpCapabilities` rather than hardcoded to `http`.

In file @apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts around lines 1135-1138:

`claudeRuntimeQueryPolicyForRuntimePolicy` leaves `allowedTools` unset for restricted read-only policies, so the `tools: ["Read", "Glob", "Grep"]` restriction is bypassed downstream: `openQuery` passes the undefined whitelist into `claudeMcpQueryOverrides`, which adds MCP tools without restriction. A restricted read-only sandbox can therefore still invoke `mcp__*` tools and escape the intended read-only limitation.

The condition on line 1136 gates `allowedTools` behind `readOnlyPolicyAllowsGlobalReads(runtimePolicy)`, so only the `fullAccess` read-only variant gets a whitelist populated. Consider populating `allowedTools` for all read-only policies (or otherwise ensuring the tool restriction applies to MCP tools as well).

In file @apps/server/src/orchestration-v2/Adapters/CursorAdapterV2.ts around line 589:

When two nested tool calls of the same type arrive without `toolCallId`, `nestedToolCallFromEnvelope` assigns both calls the identical fallback id `nested-${wrapperName}` (e.g. two `readToolCall`s both get `nested-readToolCall`). Because downstream ids are derived from `callId`, the second call overwrites the first, so only one tool artifact survives in the child thread timeline. Consider making the fallback id unique, e.g. by appending a counter or random suffix.

In file @apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts around line 1087:

`permissionModeForClaudeRuntimePolicy` silently widens an explicit `workspaceWrite` or `externalSandbox` sandbox policy to full access. For example, a policy with `runtimeMode: "full-access"`, `approvalPolicy: "never"`, and `sandboxPolicy: { type: "workspaceWrite" }` returns `"bypassPermissions"` instead of a mode that respects the sandbox restriction.

The `switch` on `sandboxPolicyKindForClaudeRuntimePolicy` falls through the `workspaceWrite` and `externalSandbox` cases without returning, so execution continues to the `runtimeMode` switch, which derives `"bypassPermissions"` from `"full-access"`. Since the adapter relies on this mapping for enforcement and never passes the sandbox policy to the SDK, the explicit restriction is lost. Consider returning a mode that preserves the sandbox boundary for those cases, or document why the fallthrough is intentional.

In file @apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts around line 693:

`claudeMcpQueryOverrides` always adds `"mcp__t3-code__*"` to `allowedTools` when an MCP session is present, but the pinned Claude Agent SDK version does not resolve wildcard entries against MCP tool names. This means every `t3-code` MCP tool call gets denied at the permission layer instead of being permitted, so the MCP-backed flow cannot execute any tool calls. The wildcard pattern needs to be expanded to concrete tool names (or handled through a different allow-list mechanism that the SDK recognizes), otherwise the MCP integration is effectively non-functional.

In file @apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts around line 139:

`CodexProviderCapabilitiesV2.streaming.streamsReasoning` is `true`, but the adapter never projects Codex `reasoning` items into any `node`, `message`, or `turn_item` events. The `item/started` and `item/completed` handlers cover `userMessage`, `agentMessage`, tools, plans, and web search, but not `reasoning`, so reasoning traces are silently dropped. Any caller that enables reasoning UI based on this capability will show empty or missing reasoning output for Codex sessions.

If streaming reasoning is not yet implemented, set `streamsReasoning` to `false` until the adapter emits reasoning items, or add handler logic that projects `reasoning` items into the appropriate events.

In file @apps/mobile/src/lib/threadActivity.ts around line 441:

`deriveThreadFeedRunFolds` collapses every entry in a completed run except the terminal assistant message, so earlier assistant messages in the same run are hidden when the run is folded. Because Orchestration V2 allows multiple assistant messages under one `runId` (e.g., commentary plus final reply), settled runs silently drop assistant-authored content unless the user manually expands the fold. The filter at `hiddenEntryIds` only preserves the entry whose `id` matches `terminalAssistantId`; it does not exclude other message entries. Consider excluding all `message` entries with `role === "assistant"` from `hiddenEntryIds`, not just the terminal one.

Also found in 2 other location(s):
- apps/mobile/src/features/threads/ThreadFeed.tsx:1529 -- `terminalAssistantMessageIds` at line `1529` is keyed only by `RunId`, so when a single run produces more than one assistant message, each later message overwrites the previous one. `showAssistantMeta` then becomes true for only the last assistant message in that run, which drops the timestamp / copy / fork controls from earlier assistant messages and, in collapsed run-fold mode, can hide earlier terminal replies from nested child threads that share the same `runId`.
- packages/client-runtime/src/state/threadCheckpoints.ts:35 -- `deriveThreadCheckpointSummaries` derives `assistantMessageId` by taking `projection.messages.findLast(...)` for the whole run. Runs can contain multiple assistant messages, so a checkpoint from an earlier assistant turn in that run will be associated with the last assistant message instead of the message that existed when the checkpoint was captured. Review/diff UI keyed by `assistantMessageId` will attach the checkpoint to the wrong response.

In file @apps/mobile/src/lib/threadActivity.ts around line 565:

`buildThreadFeed` hard-codes assistant message `attachments` to `[]`, so assistant messages that carry attachments in the server projection are rendered without them in the mobile thread feed. The code only preserves attachments for `user_message` rows; the `assistant_message` branch should propagate `item.attachments` instead of discarding them.

In file @apps/server/src/orchestration-v2/Adapters/OpenCodeAdapterV2.ts around lines 435-447:

`openCodePermissionRequestKind` returns `"file-read"` for any `external_directory` permission, but in OpenCode `external_directory` gates external writes, edits, patches, and bash workdir access — not just reads. When the tool name is unavailable (`toolName` is `undefined`) or doesn't match any read/edit heuristic, the request is misclassified as read-only, so a write-capable external-directory approval is presented and handled as a mere file-read request. Consider mapping `external_directory` to `"file-change"` (or `"command"`) so the permission reflects its actual scope.

In file @apps/server/src/orchestration-v2/Adapters/OpenCodeAdapterV2.ts around line 2386:

`resumeThread` calls only `session.get` and never applies `threadInput.runtimePolicy`, so a resumed OpenCode session keeps the permission rules it was originally created with. Since `openCodePermissionRules` is applied only at `session.create` time, resuming a thread that was created under a looser policy leaves edit/network/command permissions enabled even after the app has switched to a stricter `runtimePolicy`. The next turn on the resumed thread runs with stale, overly broad permissions instead of the requested policy. Consider re-applying `threadInput.runtimePolicy` (or re-invoking the permission-rule setup used at create time) during resume so the session's permissions match the current policy.

In file @apps/server/src/orchestration-v2/EffectWorker.ts around line 39:

`executorLayer` yields `ResourceCleanupService` during layer construction, but `ResourceCleanupService` is a `Context.Reference` with a no-op default. The layer's required environment doesn't list it, so when the layer is built without an explicit override it captures the no-op default permanently. This means `terminal.cleanup` and `attachment.cleanup` effects silently do nothing — terminals and attachments are never cleaned up. Add `ResourceCleanupService` to the layer's `RIn` type so a real implementation must be provided, or yield it per-execution instead of at construction time.

In file @apps/server/src/orchestration-v2/Adapters/OpenCodeAdapterV2.ts around line 2394:

The returned `providerThread` keeps the stale `providerInstanceId` from `threadInput.providerThread` instead of the current adapter instance's id. Only `providerSessionId` is overwritten, so resuming a thread created under a different OpenCode instance yields a `providerThread` whose `providerInstanceId` no longer matches the active instance. Downstream code filters provider threads by `providerInstanceId`, so the resumed thread cannot be matched and later turns may create a new native thread instead of continuing the conversation. Add `providerInstanceId: input.providerInstanceId` to the rebuilt object.

In file @apps/server/src/orchestration-v2/Adapters/CursorAgentSdk.ts around line 331:

When `open` is called with `operation: "resume"` and no `agentId`, the code passes `undefined` into `Agent.resume` via `input.agentId!`, causing an opaque SDK failure instead of a clear validation error. The non-null assertion suppresses the optional `agentId` without checking it. Consider validating that `agentId` is present before calling `Agent.resume` and returning a `CursorAgentSdkRunnerError` when it is missing.

In file @apps/server/src/orchestration-v2/ContextHandoffService.ts around line 126:

`makeProviderHandoffSummary` discards every prior `handoff` turn item (`if (item.type === "handoff") return []`). Because prior handoff summaries are the only persisted record of already-transferred portable context (earlier provider switches, merge-back deltas), the new handoff summary silently omits that context. On a second provider switch or resume, conversation state that existed only inside previous handoff summaries is lost. Consider including prior `handoff` items in the summary instead of skipping them.

In file @apps/server/src/orchestration-v2/Adapters/OpenCodeAdapterV2.ts around lines 569-582:

When `sandboxPolicy.type === "workspaceWrite"` and `requiresApproval` is false, the code grants `external_directory` only for entries in `writableRoots` but never processes `sandboxPolicy.readOnlyAccess`. Canonical workspace-write policies carry `readOnlyAccess: { type: "fullAccess" }`, so OpenCode sessions created under that policy deny reads from external directories that other adapters allow. Consider adding a rule for `external_directory` based on `readOnlyAccess` (mirroring the `readOnly` branch) so read-only external access is granted under `workspaceWrite` as well.

In file @apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts around lines 530-533:

`buildCodexTurnStartParams` ignores `input.runtimePolicy.reasoningEffort` and always derives `effort` from `input.modelSelection.options`. A `RuntimePolicyV2` override that sets `reasoningEffort` is silently dropped, so turns run with the model-selected or default effort instead of the requested override. This also affects plan mode, where `collaborationMode.settings.reasoning_effort` falls back to `"medium"` instead of honoring the runtime policy. Consider reading `input.runtimePolicy.reasoningEffort` first and falling back to the model-selection option only when it is absent.

In file @apps/server/src/orchestration-v2/CommandPolicy.ts around line 329:

When a run has status `waiting` (e.g., paused for approval or user input), `decideMessageDispatch` selects it as `activeRun` and then enters the `steer_active` or `restart_active` branch. Both branches require a provider turn with status `running`, but a `waiting` run has no running turn, so the function returns a `CommandPolicyMessageDispatchError` ("No running providerInstanceId turn found") instead of dispatching the message. This means messages sent while a run is waiting for approval are dropped with an error rather than delivered. Consider excluding `waiting` from the `activeRun` filter, or handle `waiting` runs without requiring a `running` provider turn.

Also found in 1 other location(s):
- apps/mobile/src/features/threads/ThreadQueueControl.tsx:98 -- `ThreadQueueControl` enables the `Steer` action whenever `workflow.canPromoteToSteer` is true, but `deriveThreadQueueWorkflowState` treats a run in `waiting` status as active. On V2 threads that are waiting for approval/user input, pressing this new Android button calls `promoteQueuedRun`, and the server's `dispatchSteerIntoRun` rejects it because the target run is not `running` and has no running provider turn. The promoted queued message therefore fails instead of being steered.

In file @apps/server/src/orchestration-v2/CheckpointRollbackService.ts around line 46:

`execute` is not idempotent, so retries after a partial success duplicate rollback side effects and append redundant events. If `eventSink.write` commits but the effect worker crashes before marking the effect complete, the at-least-once retry re-opens the provider session, calls `checkpoints.restore` and `session.rollbackThread` again, and writes another `provider-thread.updated` event with a fresh timestamp — even though the rollback already completed. Unlike `checkpoint.capture`, which guards against re-application, `execute` has no such check, so every retry-after-success path produces duplicate provider-thread mutations and extra domain events.

In file @apps/server/src/orchestration-v2/EffectWorker.ts around line 350:

When the daemon shuts down and interrupts a running effect, `Effect.exit` at line 331 captures the interruption as `Exit.Failure`. The code then treats any failure as an execution error — logging it and calling `outbox.retry` or `outbox.fail` — so a normal shutdown burns retry attempts and can permanently fail an outbox entry whose provider operation never actually failed. Consider checking `Cause.isInterrupted(exit.cause)` (or only routing non-interruption failures through the retry/fail path) so shutdown interruptions are handled separately from genuine execution errors.

In file @apps/server/src/orchestration-v2/ProjectionStore.ts around line 2288:

`getThreadSnapshot` reads the projection from `replayState` and `snapshotSequence` from `sequence` in separate `Ref` accesses. An `apply` that fires between those reads increments `sequence` without being reflected in the returned projection, so callers receive a snapshot whose `snapshotSequence` is ahead of the projection. Clients use `snapshotSequence` as the resume cursor for event streaming, so the event that landed between the two reads is skipped permanently — the client gets the older projection but starts streaming after the missing event. Consider reading both values atomically (e.g., in a single `Ref.modify`) so `snapshotSequence` and the projection always describe the same point in time.

In file @apps/server/src/orchestration-v2/ProjectionStore.ts around line 278:

In the in-memory projection, `context-transfer.created` and `context-transfer.updated` only upsert the transfer into the projection for `event.threadId`. But the SQL-backed projection exposes each transfer on both the `sourceThreadId` and `targetThreadId` threads. So when `payload.sourceThreadId !== payload.targetThreadId`, `getThreadProjection()` returns incomplete `contextTransfers` for the other thread — the transfer is silently missing from one side. Consider also upserting the transfer into the projection for the other participant thread, or document the divergence from the SQL projection if it is intentional.

In file @apps/server/src/orchestration-v2/ProviderSwitchService.ts around line 83:

`currentSession` is selected as the newest session for the current instance without excluding terminal sessions. If a newer `stopped` or `error` session exists alongside an older live session, the plan is computed from the dead session. In a `restart_and_resume` transition, `releaseProviderSessionIds` only matches that dead session's `id`, so the active live session is never released and remains attached to the incompatible model. Consider filtering out `stopped`/`error` sessions before picking the newest, so the live session is the one targeted for release.

In file @apps/server/src/orchestration-v2/ProviderEventIngestor.ts around lines 128-129:

In `makeDomainEvent`, `payloadInput.runId ?? input.runId` and `payloadInput.nodeId ?? input.nodeId` (lines 128–129) use nullish coalescing, so an explicit `null` in `payloadInput` is replaced with the parent value from `input`. This mis-tags provider artifacts that intentionally live outside a run — such as child-thread messages with `runId: null` — as belonging to the current root run, and downstream projection code silently leaks those artifacts into the parent run. Consider using a check that only falls back when the field is `undefined`, so an explicit `null` is preserved.

In file @apps/server/src/orchestration-v2/ProviderTurnControlService.ts around line 130:

`load` returns a `ProviderTurnControlError` when `providerTurn.status` is still `"running"` but the provider session runtime is already gone (`sessions.get` returns `Option.none()`). Because terminal provider events are projected asynchronously on a detached ingestion fiber, a turn can finish and have its runtime removed before the projection reflects the status change. In that window, `interrupt` and `interruptAndAwaitTerminal` fail spuriously for a turn that has already terminated, instead of treating the missing runtime as already-terminal and no-oping (or waiting for the projection to catch up). Consider returning a no-op result when the session is missing but the turn is still marked `running`, rather than failing immediately.